Description

Adds resource command argument metadata and command visibility support across hosting, dashboard, CLI, MCP, and polyglot code generation.

This change:

• flows command InteractionInput metadata through resource snapshots, dashboard service contracts, JSON resource output, and the auxiliary backchannel
• exposes submitted command arguments to handlers as a non-null InteractionInputCollection, matching the interaction service result model
• keeps JSON/protobuf handling in the CLI, dashboard, MCP, and auxiliary backchannel transport layers instead of exposing raw JSON on the command API
• adds typed C# convenience accessors on InteractionInputCollection for common command argument reads (GetString, GetBoolean, GetInt32, GetDouble) and a TypeScript intrinsic with idiomatic helpers (toArray, get, required, value, requiredValue)
• adds CLI forwarding for ordered loose command arguments; the AppHost maps those values onto declared CommandOptions.Arguments by order and performs validation centrally
• adds built-in and custom command argument validation that flows field errors back to Dashboard interactions, CLI, MCP, and auxiliary backchannel callers without invoking the command callback
• adds command visibility metadata so commands can be exposed to dashboard clients, API clients, or both
• updates polyglot SDK snapshots and RemoteHost scanner coverage for the new command option surface
• preserves the previously shipped ResourceCommandAnnotation constructor for compatibility
• adds Stress playground command samples that exercise common and less common API usage end-to-end

API sample from the Stress playground common command:

serviceBuilder.WithCommand(
    name: "echo-arguments",
    displayName: "Echo arguments",
    executeCommand: context =>
    {
        var arguments = ReadEchoCommandArguments(context.Arguments);
        var message = arguments.Shout ? arguments.Message!.ToUpperInvariant() : arguments.Message!;
        var payload = new
        {
            arguments.Message,
            arguments.Repeat,
            arguments.Shout,
            arguments.Flavor,
            SecretLength = arguments.Secret?.Length ?? 0,
            Echoed = Enumerable.Repeat(message, arguments.Repeat).ToArray()
        };

        return Task.FromResult(CommandResults.Success(
            "Echoed command arguments.",
            new CommandResultData
            {
                Value = JsonSerializer.Serialize(payload),
                Format = CommandResultFormat.Json,
                DisplayImmediately = true
            }));
    },
    commandOptions: new CommandOptions
    {
        Description = "Common dashboard/API command with text, number, boolean, choice, and secret argument inputs.",
        IconName = "Code",
        Arguments =
        [
            new InteractionInput { Name = "message", Label = "Message", InputType = InputType.Text, Required = true, MaxLength = 80 },
            new InteractionInput { Name = "repeat", Label = "Repeat", InputType = InputType.Number, Value = "1" },
            new InteractionInput { Name = "shout", Label = "Shout", InputType = InputType.Boolean, Value = "false" },
            new InteractionInput
            {
                Name = "flavor",
                Label = "Flavor",
                InputType = InputType.Choice,
                Value = "vanilla",
                Options =
                [
                    KeyValuePair.Create("vanilla", "Vanilla"),
                    KeyValuePair.Create("chocolate", "Chocolate"),
                    KeyValuePair.Create("strawberry", "Strawberry")
                ]
            },
            new InteractionInput { Name = "secret", Label = "Secret", InputType = InputType.SecretText }
        ]
    });

static EchoCommandArguments ReadEchoCommandArguments(InteractionInputCollection arguments)
{
    return new EchoCommandArguments
    {
        Message = arguments.GetString("message"),
        Repeat = arguments.GetInt32("repeat"),
        Shout = arguments.GetBoolean("shout"),
        Flavor = arguments.GetString("flavor") ?? "vanilla",
        Secret = arguments.GetString("secret")
    };
}

Custom command argument validation uses the same pattern as interaction input validation. Built-in validation runs first (required, max length, choice membership, boolean, and number parsing). Interactive Dashboard execution prompts through the AppHost interaction service, so validation keeps the input dialog open with field errors. CLI/MCP execute non-interactively and receive structured argument errors:

commandOptions: new CommandOptions
{
    Arguments =
    [
        new InteractionInput { Name = "target", Label = "Target", InputType = InputType.Text, Required = true }
    ],
    ValidateArguments = context =>
    {
        var target = context.Inputs.GetString("target");
        if (string.Equals(target, "prod", StringComparison.OrdinalIgnoreCase))
        {
            context.AddValidationError("target", "Target must not be prod.");
        }

        return Task.CompletedTask;
    }
}

TypeScript AppHosts get the same command argument API with idiomatic JavaScript conversion instead of C#-style GetInt32 helpers. ExecuteCommandContext.arguments and InputsDialogValidationContext.inputs are generated as async getter methods, so await context.arguments() returns command arguments and await context.inputs() returns validation inputs:

import {
    InputsDialogValidationContext,
    ExecuteCommandContext,
    InputType
} from './.modules/aspire.js';

const cache = await builder.addRedis("cache");

await cache.withCommand(
    "set-prefix",
    "Set prefix",
    async (context: ExecuteCommandContext) => {
        const args = await context.arguments();
        const prefix = await args.requiredValue("prefix");
        const count = Number(await args.requiredValue("count"));

        return {
            success: true,
            message: `Validated prefix '${prefix}' with count ${count}.`
        };
    },
    {
        commandOptions: {
            description: "Validates ordered command arguments from the CLI and Dashboard.",
            arguments: [
                {
                    name: "prefix",
                    label: "Prefix",
                    inputType: InputType.Text,
                    required: true,
                    maxLength: 20
                },
                {
                    name: "count",
                    label: "Count",
                    inputType: InputType.Number,
                    required: true
                }
            ],
            validateArguments: async (context: InputsDialogValidationContext) => {
                const args = await context.inputs();
                const prefix = await args.requiredValue("prefix");
                const count = Number(await args.requiredValue("count"));

                if (prefix.toLowerCase() === "bad") {
                    await context.addValidationError("prefix", "Prefix cannot be 'bad'.");
                }

                if (!Number.isFinite(count) || count < 1) {
                    await context.addValidationError("count", "Count must be greater than or equal to 1.");
                }
            }
        }
    });

The TypeScript InteractionInputCollection wrapper caches the backing input array and exposes:

const args = await context.arguments();
const allInputs = await args.toArray();
const maybePrefix = await args.value("prefix");
const prefixInput = await args.required("prefix");
const prefix = await args.requiredValue("prefix");

Getter-only fluent APIs can now be chained naturally in TypeScript. The generated promise wrapper remains awaitable, so both styles work:

await ctx.environment().set("API_ENDPOINT", refExpr`${endpoint}`);

const environment = await ctx.environment();
await environment.set("API_ENDPOINT", refExpr`${endpoint}`);

CLI resource command arguments are passed as ordered values, not matched by input name. For example, the echo-arguments sample can be invoked as:

aspire resource stress-apiservice echo-arguments "Hello E2E" 2 true chocolate sauce --apphost playground/Stress/Stress.AppHost/Stress.AppHost.csproj

The CLI captures loose/overflow tokens in order and sends them as a JSON array over the auxiliary backchannel. CLI/MCP execute non-interactively so missing or invalid arguments fail fast with structured errors. Dashboard command execution leaves argument prompting to the AppHost interaction service, which renders the standard inputs dialog in the Dashboard and supports server-side validation/dynamic updates.

The Stress playground also includes:

• echo-command-arguments: small API-only primitive argument command using ResourceCommandVisibility.Api
• validate-arguments: validation/failure command using required inputs, defaults, choices, custom argument validation, and structured JSON failures
• argument-stress-test: minor dashboard/API stress command with 23 argument inputs to exercise metadata, rendering, submission, and payload handling

Fixes # (issue)

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire.dev issue:
      • New issue
  • No